Software development environments are computing environments that support both (i) a production (or “official”) platform, and also (ii) informal workspaces that are derived from the official and which developers use on their own private computing devices to develop new features, enhancements, diagnostics, and/or bugfixes. Typically, the production platform comprises a software base (including, e.g., source code, files, configuration parameters, scripts, etc.) for building executable code and/or binary files (the “executable software files”). Executable software file(s) may be provided to customers as an official release, e.g., version 1.0.
A “patch” or “software patch” may be needed after a given official release has been distributed to customers. A patch may functionally comprise new features, enhancements, bugfixes, and/or diagnostics that incrementally modify the official release. Any given patch may contain one or more binary files, which are executable software files. For a new official release to ultimately issue, each patch needs to be “built” so that its component binary file(s) are properly integrated with the existing set of executable software files—this is called a “working build.” Thus, a working build is defined by a set of executable software files. A patch takes time to build ranging from a few minutes to a few hours. Patches may have dependencies amongst themselves that prevent them from building in parallel due to functionality reasons, for example. Hence patches need to be queued and hence a requirement for patch-queue management. Typically, a computer (a so-called “build server”) may be dedicated to managing patch intake and integration/building. Typically the build server generates and maintains the working build, which incrementally incorporates one patch at a time. The working build and successive working builds may be stored on a storage device such as a storage array. The working build may eventually be closed to new patches and the set of executable software files in the present working build may be distributed to customers as a new official release or service pack, e.g., version 1.1.
Workspaces are private developer copies that may be derived from an official software base. Typically, a developer obtains a copy of the official software base to use as a workspace on her/his own computing device for generating additional software (e.g., source code, files, configuration parameters, scripts, etc.) that may perform a particular function, such as a feature, an enhancement, a bugfix, a diagnostic, etc. The workspace containing the developer's software may be processed into a patch (i.e., including binaries file(s)) and may be submitted for integration into the working build. An exemplary prior-art approach to managing the submission and integration of patches into a working build is presented in FIG. 1 and generally depicts the processing of submitted patches in chronological order as they arrive at the build server in a “first-in first-out” scheme.
FIG. 1 depicts a typical prior-art First-In First-Out (“FIFO”) approach to managing patch submissions in a software development environment 100. FIG. 1 depicts: developer machines 102-1 through 102-n; build server 103, comprising patch queue 110 and patch builder-integrator 112; and storage device 104 comprising working build 114. The components may be physically interconnected by any suitable communications infrastructure that is well known in the art, such as the logical communication pathways depicted by bi-directional solid arrows 131-1 and 132. The uni-directional solid arrows depict logical data flows within software development environment 100, which may be supported by the underlying communications infrastructure.
Developer machines 102 (e.g., 102-1, 102-2, 102-3, . . . , 102-n) are computing devices assigned to respective individual developers. A computing device such as developer machine 102 may be, without limitation, a workstation, personal computer, desktop computer, or other type of generally fixed computing system such as a server, mainframe computer, or minicomputer; a mobile or portable or untethered computing device, such as a laptop, a tablet computer, a personal data assistant, a mobile phone (such as a smartphone); and/or another kind of fixed, mobile, or portable computing device such as an embedded computer, set top box, vehicle-mounted device, wearable computer, etc. A developer machine 102 comprises one or more processors (e.g., a CPU comprising one or more processor units and/or single-core or multi-core processor(s), etc.) and non-transitory computer-readable memory (e.g., random access memory (RAM)) for storing executable computer-readable instructions such as computer programs and/or applications that may be executed therefrom by the one or more processors. A developer machine 102 may comprise additional computer-readable memory for mass data storage, e.g., a hard disk, and/or may be associated with and/or have networked access to a mass storage device such as a storage array, e.g., storage device 104. Patches are submitted, usually one patch at a time, for integration into a working build maintained by build server 103, and e.g., working build 114. Each developer machine 102 may communicate with build server 103 via a respective communication pathway 131. A developer machine 102 operating in software development environment 100 may perform one or more of the following functions:                Establish communications with build server 103, e.g., using a respective communication pathway 131.        Submit one or more software patches, e.g., patch A, patch B, etc., to build server 103 for integration into the working build.        Receive communications from build server 103, e.g., integration and build status.        
Build server 103 is a computing device, well known in the art, which is generally directed at maintaining a working build. In the present example, build server 103 may perform one or more of the following functions in software development environment 100:                Establish communications with one or more developer machines 102, e.g., via respective communication paths 131.        Establish communications with a storage device, e.g., 104, which stores the official working build, e.g., via communication path 132.        Receive submitted patches from developer machines 102 and track the received patches in one or more appropriate data structure(s) such as patch queue 110.        Extract the patches from the patch queue, one at a time, in a first-in first-out order, for integration into the working build.        Integrate each patch into the working build (“build the patch”), resulting in an updated working build that comprises the integrated patch. In the present example, the integration function of build server 103 is performed by a patch builder-integrator 112.        Store the updated working build to a storage device, e.g., 104.        Back up and protect the working build, e.g., generate secondary copies, instruct another component to generate secondary copies, store the secondary copies to appropriate storage devices, etc.        Prepare an official release from a working build, e.g., version 1.1 or service pack 1.1.2, etc.        Communicate with and/or respond to other components of development environment 100 (not shown here), e.g., a storage manager, another storage device, etc.        
Storage device 104 may be a high-capacity mass storage device that is well known in the art, such as a storage array. Storage device 104 stores working build 114 and may additionally store any number of versions of working build 114 (not shown). Version management may be performed by build server 103, and is well known in the art.
Patch queue 110 is an illustrative data structure, maintained by build server 103, which data structure comprises any number of submitted patches that are awaiting integration into working build 114. Patch queue 110 may be maintained in a local memory in build server 103, such as in a cache, or may be physically stored in a connected storage device, such as storage device 104. Patch queue 110 may comprise pointers to the actual patches which may be large groups of binary files and may be stored elsewhere, e.g., in storage device 104. As illustrated here, patch queue 110 logically collects patches as they arrive from various developer machines 102, in the following illustrative sequence:                First in time, Patch A from developer machine 102-1;        Second in time, Patch B from developer machine 102-2;        Third in time, Patch C from developer machine 102-3;        Fourth in time, Patch D from developer machine 102-n; and        Fifth in time, Patch E from developer machine 102-3.        
A patch or “software patch” such as Patch A, Patch B, etc., may comprise one or more binary files. Patch queue 110 is not drawn to scale and the size of each submitted patch may vary dramatically from one patch to another. For example, one patch may comprise two files, whereas another one may comprise one hundred files. Each patch may have an identifier that is unique in software development environment 100.
Patch builder-integrator 112 is a functional module that executes on build server 103 and which incorporates patches into working build 114. In the present example, as is typical with prior-art approaches to software integration, the patches are extracted from patch queue 110 in a first-in first-out (or “FIFO” or “first come first serve”) scheme. In the present example, once Patch A is integrated and working build 114 is updated, patch builder-integrator 112 extracts and integrates Patch B, then moves on to Patch C, then to Patch D, and finally to Patch E, thus reflecting the chronological time sequence in which these patches were received by build server 103. As shown herein, this FIFO scheme may be disadvantageous in certain scenarios.
Patch builder-integrator 112 is shown here as a unitary module to ease the reader's understanding of the present disclosure. Patch builder-integrator 112 may be a collection of separate and/or interconnected and/or interoperating modules that perform one or more of the enumerated functions, e.g., extracting patches in a FIFO scheme from patch queue 110; integrating each patch into an existing working build 114; storing the updated working build 114 comprising the integrated patch to storage device 104, etc.
Working build 114, which is stored in storage device 104, is well known in the art and may comprise any appropriate number and size of binary files, which collectively form a set of executable software files. Thus, the set of executable software files logically form—working build 114. These constituent files may be stored in any manner well known in the art in a suitable storage device, such as a storage array. Working build 114 may execute on any suitable target computing device, e.g., Windows-based, Unix-based, etc. Working build 114 changes after every patch is integrated thereinto (or “built”). Therefore, several versions of working build 114 may be maintained by build server 103, e.g., full backups, incrementals, etc. These mechanisms are all well known in the art. The working build may eventually close to new patches and the set of executable software files in the build may be distributed to customers as a new official release or service pack, e.g., version 1.1, version 1.1.2, etc.
Logical communication pathways 132 and 131 (e.g., 131-1, . . . , 131-n) may be supported by any suitable underlying physical electronic communications infrastructure that is well known in the art. For example, logical communication pathways 131 and 132 may include one or more networks or other connection types including one or more of the following: the Internet, a wide area network (WAN), a local area network (LAN), a Small Computer System Interface (SCSI) connection, a Fibre Channel connection, a virtual private network (VPN), and/or other appropriate computer or telecommunications networks, combinations of the same or the like.
Integrating a patch may take from a few minutes to an hour or more, depending on the complexity of the submitted patch. The present figure illustrates only a handful of patches awaiting integration in patch queue 110. However, the number of development machines 102 may well reach into the hundreds and may be scattered around the world. In some scenarios, the FIFO approach to extracting and integrating patches may slow down the overall integration process and result in the working build not being available for downstream operations, such as deliveries to system test and responding to customer escalations. Developer time may be wasted while waiting for integration to complete. Thus, FIFO integration may work against business objectives. It would be desirable, therefore, to operate with a more scalable and flexible scheme.